「ストレッチゾーンに挑戦し続ける」ことって難しくないですか？ メンバーの持続的成長を支えるEMの環境設計
プロダクトとして120人規模の開発組織
ストレッチゾーンに注目したきっかけ
モバイルアプリ開発組織
シニアiOSエンジニアが相次いで退職
理由：キャリアの停滞感
個人として無力感と後悔
できることがあったのでは？
マネージャーは停滞感を産まないこと
=> ストレッチゾーンなチャレンジが枯渇した？
1on1で確認を進めた
パターン
最適なチャレンジがわからない
現状を分析するのが有用
Will/Can/Must
リクルートのフレームワーク
難しいケース
Willの言語化が難しい
例：技術力高くなりたい
特定技術のエキスパート？
カンファレンス登壇？
ビジネスを動かしたい？
Mustと噛み合わずアクションが生まれない
レガシーコードを刷新したいけど...
具体と抽象によるリフレーミング
なぜWillをしたい？
再度Howを具体化
自然消滅しそう：忙しさなど
目標を立てる
ストレッチな課題は不安がつきまとう
簡単な仕事のほうに進みたくなる
目標設定はコンフォートゾーンの誘惑を断ち切る
結論：むずかしかった
低い目標設定をしてしまう
忙しくて取り組めなかったがズルズル進む
メンバー内で目標の可視化
可視化したことにより協力が促せた
定期的な議論により変化に対応しやすくなった
別の目標に切り替えることができる：機会損失を防ぐ
スナッキングの誘惑に負けない
外部要因で止まりそう
実行支援
期待値のドキュメントを作る
チームリーダーを任せる目標設定
=> 権限委譲を明確にする
ストレッチな目標は大きな変化を起こす取り組みになりがち
自分が決めていい範囲がわからない => アクションを阻害
この先待っていたのは
スケールの壁
1on1の時間が不足するようにあった
後悔目標、定期進捗確認などが消滅
マネージャーがボトルネックにならない仕組み作りが必要
仕組みづくり
難しい
運用し続けるコスト
現状維持バイアス
他部署からの期待値
予期せぬ副作用
イベントはしているが改善が回っていない
=> 現実世界の複雑さ
部分に分割するのではなく、システム全体を変える
因果ループ図で解決
=> レバレッジポイントの仮説を立てる
まとめ
ミドルマネージャーが鍵